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ABSTRACT 

The X-33 vehicle is an advanced technology 
demonstrator sponsored by NASA. For the past 
three years the Structural Dynamics & Loads 
Group of NASA's Marshall Space Flight Center 
has had the task of integrating the X-33 vehicle 
structural Finite element model. In that time, five 
versions of the integrated vehicle model have been 
produced and a strategy has evolved that would 
benefit anyone given the task of integrating 
structural Finite element models that have been 
generated by various modelers and companies. 
The strategy that has been presented here consists 
of six decisions that need to be made. These six 
decisions are: purpose of model, units, common 
material list, model numbering, interface control, 
and archive format. This strategy has been proved 
and expanded from experience on the X-33 
vehicle. 

INTRODUCTION 

The responsibility for large structures rarely rests 
in the hands of a single institution any longer. The 
responsibility is now being spread across a larger 
number of industry partners. So too is the 
responsibility for the structural finite element 
models used for assessing these structures. This 
broad effort often needs to be refocused into an 
integrated model that reflects characteristics of the 
full system. This is the task of the model 
integrator. 

Attempts have been made in the past to provide 
tools to the model integrator to simplify this task. 
ALAS' is an example of a tool that attempted to 
simplify some of the analytical aspects of the 
integration task. Many of today’s computer-aided 
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engineering or CAE packages have various tools 
and degrees of success supporting this process. 
MSC/SuperModel is one of the latest tools to put 
forth a system for simplifying this process 1 2 ’'. It 
itself is based on tools developed in house at the 
old McDonnell-Douglas Aircraft Corporation 
similar to in-house tools developed at many 
companies. Even with these current and 
developing tools most of the modelers involved in 
the project likely use different CAE packages. 
This offers its own challenges to the integrator. 

For the past three years the Structural Dynamics & 
Loads Branch of NASA’s Marshall Space Flight 
Center has had the task of integrating the X-33 
vehicle structural finite element model. In that 
time, five versions of the integrated vehicle model 
have been produced. A great number of lessons 
were learned in this process. Presented here is a 
strategy that, if used at the outset of the project, 
will pave the way for a smooth integration. This 
strategy would benefit anyone given the task of 
integrating structural Finite element models that 
have been generated by various modelers and 
companies. This strategy also provides benefits 
regardless of the tools used to help the integrator in 
this task. 

THE X-33 MODEL INTEGRATION 
PROBLEM 

The X-33 vehicle is an advanced technology 
demonstrator sponsored by NASA. The X-33 
program will demonstrate, in flight, the new 
technologies needed for a reusable launch vehicle 
using a half-scale prototype. NASA has selected 
Lockheed-Martin Skunkworks to design, build, and 
fly the X-33 test vehicle. The industry team, with 
Lockheed-Martin Skunkworks as lead, includes 
Lockheed-Martin Michoud, B.F. Goodrich 
(previously Rohr), Boeing Rocketdyne, and 
NASA. 

The X-33 has a complicated and highly coupled 
structural design. It consists of a liquid oxygen tank 
sitting on top of a pair of side-by-side liquid 
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hydrogen tanks. Behind and in-between the 
hydrogen tanks arc the two aerospike engines. 
Over all of this is a complex aeroshell structure that 
provides thermal protection and the aerodynamic 
shape of the lifting body. The canted and vertical 
fins and body flaps are also attached to the thrust 
structure. 

In order to assess the design, an integrated vehicle 
finite element model was required to determine 
internal loads. These internal loads were derived 
from externally applied forces in both static and 
transient dynamic loads analyses. The required 
model was generated from individual major 
structure models obtained from across the industry 
team. Models of the liquid hydrogen tanks, thrust 
structure, intertank, and landing gears were 
provided by Lockheed-Martin Skunkworks. The 
liquid oxygen tank model was provided by 
Lockheed-Martin Michoud. The Aerospike engine 
model was provided by Boeing Rocketdyne. B.F. 
Goodrich provided models of the canted fin control 
surfaces. The Structural Dynamics & Loads 
Branch of NASA’s Marshall Space Flight Center 
had the task of modeling the aeroshell, body flap 
control surfaces, canted and vertical fins, and the 
rotating launch mount. The Structural Dynamics & 
Loads Branch also had the task of integrating the 
various models into the full vehicle model. 

The integrated vehicle model that resulted has had 
five versions. Four complete loads analysis cycles 
have been completed. These include static pre- 
launch, ascent, descent, landing, and transient 
liftoff analyses. A fifth loads cycle is underway. 
The models have also been used to assess dynamic 
characteristics for flight control analyses. The 
model grid count peaked at 29427 grids for load 
cycle 4 and is now down to 20400 grids for load 
cycle 5 after a concerted effort to reduce the model 
size. 

STRATEGY FOR MODEL 
INTEGRATION 

The strategy presented here consists of six 
decisions that need to be made at the outset of the 
project. These decisions, once made and agreed to 
by the modeling team, will pave the way for a 
smooth model integration. These six decisions are: 
purpose of model, units, common material list, 
model numbering, interface control, and archive 
format. Each is discussed in detail below. 


Purpose Of Model 

The first decision to be made is the purpose of the 
model. Is it a stress model? Is it a loads model? A 
dynamics model? This decision drives many of the 
following decisions. In particular it defines the 
scope of the model and therefore the approach to 
the modeling. It would also have a direct impact 
on the size of the model. The effort for X-33 was 
to develop a model that would be used to recover 
internal element forces for use by stress analysts. 
It was never intended to recover stresses as this 
would have led to a model that would be all but 
impossible to run. It was also meant to adequately 
represent elastic modes from 0 to approximately 25 
HZ so that liftoff transient loads could be 
recovered. These dynamic characteristics were 
also to be used for control stability studies and 
POGO analyses. During the entire development of 
the model it was a continual challenge to balance 
the need for accurate forces (not stresses) and 
dynamics and still have a reasonably sized model. 
Accommodations also had to be made, both in 
increased and decreased Fidelity, when it was 
decided the model would also be used for flutter 
analyses. 

It should be noted here, that on the X-33 project 
two model "styles" existed. One style of modeling 
consisted of modeling the structure the way it was 
intended to work. For example, modeling web 
caps with rod elements because they were 
primarily intended to carry axial load. The other 
style modeled the structure the way it was drawn or 
built in order to verify the assumptions used in 
design. For example, the web caps were modeled 
with bar elements to verify that the axial load was 
the only significant load. Every modeler uses a 
combination of these styles. The reasons include 
preference, economy, time, and maturity of design. 
There is little expectation that the modeling can be 
controlled to the point of requiring a consistent 
style. However, the model integrator needs to be 
aware of these styles so that any issues that come 
up because of them can be quickly recognized and 
settled. 

Units 

The units of measure the model will use need to be 
decided. This could be of great importance if the 
model is a joint venture between European and US 
modelers. Even if the standard units used by the 
modelers are similar, care should be taken, 
especially with mass vs. weight units. While in the 
US most aircraft modelers commonly use inches, 
density poses a problem. Many modelers use 
weight density but also, many modelers use mass 
density. The desired units for the integrated model 
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should be decided very early so the individual 
modelers can accommodate this. This was not 
done on X-33, so a number of models had to have 
their densities converted. Fortunately all models 
were in inches. 

Common Material List 

The next things to determine are material 
properties. It would be very advantageous to 
establish a common material list for use by all the 
modelers. The advantage would be a consistent set 
of properties between modelers and therefore no 
redundancy in material definitions. Even though 
the materials might be standard there are many 
variations in alloys and thermal characteristics. 
This list would obviously grow and change as the 
design evolves but it should be a simple matter to 
provide regular updates. Even if a particular model 
needed some specialized properties it would start 
with a common base. 

In conjunction with the common materials list, the 
ambient temperature of each model should be 
defined. This could have a large effect on the 
material properties used for that model. For 
example composite material properties are much 
more dependent on temperature than metals, but 
even aluminum has significant changes at 
cryogenic temperatures such as the liquid oxygen 
tank for the X-33. Also thermal protection 
materials drastically change properties over their 
expected temperature ranges. Several different 
material definitions may be necessary for the same 
material because of its use in different areas. For 
example a composite material may be used in a 
cryogenic liquid hydrogen tank and also a hot 
thermal protection support beam and therefore 
have two different material definitions. A common 
reference temperature and units for coefficients of 
thermal expansion should also be established to 
facilitate a thermal contraction or expansion 
assessment. 

The use of a common materials list would also 
allow for easier changing of material properties for 
assessment of different temperature profiles of the 
integrated model. For example the ascent 
temperature profile of the X-33, and therefore its 
material properties, may be drastically different 
from the descent profile. You may therefore have 
a different common material list for each 
temperature profile with the same material 
identification. These lists could then be exchanged 
to assess the model for the different profiles. 

Invariably, somewhere, the model will use a "stiff* 
bar or plate where an RBAR won’t do or use stiff 


springs to recover interface loads in the global 
coordinate system. It would be good to define 
these materials and properties in the common 
material list also, so all the modelers could be 
consistent and reduce redundant definitions. 

The value of the MSC/NASTRAN parameter 
K6ROT for drilling stiffness in shell elements 
should be decided early. Some modelers depend 
on a large value of K6ROT to alleviate drilling 
stiffness problems. Others depend on zero or low 
values of K6ROT to allow some freedom in this 
direction. Even if you can specify different 
K6ROT parameters for different Super Elements it 
is a good idea to specify a default value so the 
modelers may accommodate it with other 
techniques. 

Neither the common materials list or temperature 
profiles were established for the X-33 model and 
this has caused a certain amount of aggravation 
throughout its evolution. Such a list would also be 
of great benefit to model correlation efforts at a 
later date. It may still be necessary to go back and 
establish this list but it would have been much 
easier to have established it from the start. 

Model Numbering 

Assigning node number ranges to the different 
models is fairly common practice. You may want 
to specify a target number of grids to help limit the 
size of the model, but be sure to allow adequate 
room for inevitable growth. Enforce the 
numbering not only on nodes but also elements, 
properties, rigid elements and multi-point 
constraints. Rigid elements and multi-point 
constraints can cause difficulties. 
MSC/NASTRAN and MSC/PATRAN sometimes 
treat them as elements and sometimes treat them as 
separate entities. This can particularly be a 
problem if you later decide to use Super Elements. 
Older versions of MSC/NASTRAN would allow 
an element and a rigid element to have the same 
number in a standard analysis but not in a Super 
Element analysis. To be safe, make sure their 
numbering is exclusive of the elements. The 
material numbering should be from the common 
material list but if a special material is needed 
enforce the numbering range. And finally, make 
the ranges different enough that you can easily 
identify the model an element, node, or property 
belongs to. 

Interface Control 

If at all possible an Interface Control Document or 
ICD should be established for the different model 
pieces. This is a document that defines the 
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interface geometry and loads between different 
portions of the model or structure. For the most 
part this data is already contained in structural 
ICDs. For X-33 this was true for interfaces 
between companies such as B.F. Goodrich and 
Lockheed-Martin Skunkworks or Lockheed-Martin 
Michoud and Lockheed-Martin Skunkworks. 
Lockheed-Martin Michoud’s ICD (Figure 2) was 
particularly well done and was invaluable in 
interfacing the liquid oxygen tank model with other 
models. Much of the X-33 was designed within 
the same company and did not have a structural 
ICD. It would be very beneficial to establish such 
ICDs for the purposes of the models even if they 
are not rigidly controlled documents. They might 
also help define better divisions of responsibility 
for the model pieces. An example for X-33 would 
be the aeroshell ring frames over the liquid 
hydrogen tanks. The ring frames modeling 
responsibility belonged to the aeroshell modeler 
and the tank modeling responsibility to another. 
Since the ring frames attached continuously to the 
tanks a great deal of coordination was required to 
make the model meshes match. A better approach 
might have been to let the tank modeler model the 
ring frames and define an ICD for the frame to 
aeroshell interface. This would still require 
coordination but the interface would be better 
defined and more along structural lines rather than 
model meshes. 

In instances where the interface between structures 
should only pass loads or allow compliance in 
certain directions the ICD should carefully indicate 
which side these releases are modeled. The 
structural ICD should make this clear, however 
many modelers that are only concerned with one 
side of the interface will not make any provisions 
for special releases except through model 
constraints. These constraints are then lost upon 
integration and it is left to the integrator to fix the 
problem, usually with springs or rigid elements. 
This is not necessarily the most efficient method. 
This problem occurred with regularity on the X-33 
project. 

Archive Format 

The format for storing and transmitting the model 
data needs to be decided. For X-33, this was 
decided to be the MSC/NASTRAN bulkdata. This 
decision was made for two primary reasons. First, 
because the modeling effort spanned several 
companies that used various computer-aided 
engineering or CAE packages, even different 
versions of those packages, the bulkdata was 
deemed the most portable. MSC/NASTRAN was 
the most common denominator. Secondly, even 


though the CAE translators to MSC/NASTRAN 
are continually improving, they are not perfect. 
Since these models would be passed back and forth 
many times and passed through CAE translators 
multiple times it was decided that the bulkdata 
would be the trusted copy. Any modifications that 
were made with the help of the CAE packages 
would be output to MSC/NASTRAN but then text 
edited into the archive bulkdata format. In fact, for 
X-33, most errors between model versions were 
traced back to passes through the CAE packages 
where beam orientations, section properties, and 
material definitions were compromised. Bulkdata 
comments could also be preserved with this cut and 
paste method. 

For X-33, it was also decided that the separate 
models would remain in separate files and 
assembled using "include" statements in the 
MSC/NASTRAN analysis File. This provided ease 
of updates for portions of the model that were in 
various stages of flux and design. A sub model’s 
included bulkdata file could easily be replaced with 
a new one as updates were made without affecting 
the rest of the model. Also, had the common 
material list been used this would be a convenient 
way of using it. This decision, as beneficial as it 
was, created one problem. On the one hand, 
MSC/NASTRAN does not allow duplicate grid 
definitions. This prohibited having grid definitions 
in both bulkdata Files for models that interfaced. 
On the other hand, the CAE packages cannot read 
in the bulkdata for a sub model without this grid 
definition. For example, SDRC IDEAS would not 
read in any of the file if there was such an error 
while MSC/PATRAN would not read in affected 
elements but would read the rest of the file. 

One suggestion for handling this problem was that 
each sub model have completely unique grid 
numbers and then have an additional interface file 
that contained connecting springs or rigid elements. 
This could be an effective method for a relatively 
simple model with few interfaces but for this 
highly coupled structure the cost of additional grids 
and elements would be prohibitive. Also it would 
be very difficult to ensure absolutely coincident 
grid points that are required for this method to 
work correctly. 

The solution decided on for X-33 was that within a 
sub model bulkdata file all grid definitions that 
interfaced with other sub models would be placed 
in the bottom of the bulkdata file where they could 
be easily found (Figure 3). Further, the bulkdata 
files would be considered in an 
upstream/downstream fashion similar to Super 
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Elements. The sub model hulkdata files were 
named with a preceding number to facilitate this 
upsircam/downstream ordering. An interface grid 
was defined once in an upstream bulkdata file. 
When it was referenced in a downstream bulkdata 
file its definition would be commented out with a 
unique integration comment such as "$INTEG $". 
Thus when all bulkdata files were included in the 
MSC/NASTRAN analysis file no duplicate grid 
definitions would result. If it was necessary to read 
a bulkdata file into a CAE package or have a 
checkout analysis done by itself then all 
occurrences of the "SINTEG $” comment would be 
changed to nothing in a text editor first. 

USE OF MSC/PATRAN IN MODEL 
INTEGRATION 

MSC/PATRAN was the CAE package used for the 
model integration. This was a difficult task made 
relatively easy by several of MSC/PATRANs 
features associated with creating and displaying 
groups. Lockheed-Martin Michoud reported great 
difficulty completing similar tasks with SDRC 
IDEAS. In particular, MSC/PATRAN offered a 
unique benefit to this integration process. With the 
sub model bulkdata files defined as they were, they 
could be read into MSC/PATRAN to form an 
integrated model database as long as the Files were 
read in the proper order. This could be done 
without having to edit out the "$INTEG $” 
comments. In addition this process was vastly 
aided by the use of a journal file. The journal file 
was constructed to create a group, set it as default, 
and then read the bulkdata and repeat for the next 
file. With this journal file it was extremely easy to 
reconstruct integrated model databases for viewing 
results. It was also very easy to establish an X-33 
template for use by other engineers. For the other 
companies that used MSC/PATRAN, but had 
different versions on different machines, this was a 
convenient way of providing them with a database. 

PITFALLS ENCOUNTERED WITH 
MSC/PATRAN 

The largest MSC/PATRAN pitfall encountered lies 
in the association, in the database, of the beam 
orientation vectors with the property rather than the 
element. The X-33 model has a large number of 
beam elements with the same cross sectional 
properties but different orientations. The 
orientations were not easily defined by a 
MSC/PATRAN field so a different property was 
required for each while defining them in the 
database. These were later text edited, in the 


bulkdata file, to reference the same property card. 
On reading this bulkdata file back into 
MSC/PATRAN, the property remained a single 
property entry with a MSC/PATRAN spreadsheet 
field for the orientation. This was convenient when 
checking beam properties. However, when it was 
desired to add a new beam based on the existing 
property the output beam orientation was 
undefined and had to be text edited later in the 
bulkdata file. 

Another pitfall was described in Section 3.5 above, 
regarding translation between the CAE package 
and the bulkdata. Even MSC/PATRAN and 
MSC/NASTRAN had this problem, although it was 
worse with other CAE packages. In fact, for X-33, 
most errors between model versions were traced 
back to passes through the CAE packages where 
beam orientations, section properties, and material 
definitions were compromised. 

One other pitfall occurred regarding the translating 
of the bulkdata into MSC/PATRAN. This problem 
came with the switch from MSC/PATRAN 6.2 to 
MSC/PATRAN 7.0. The model contained a set of 
multi-point constraints or MPC’s that were defined 
on multiple MPC cards but having the same MPC 
number. MSC/NASTRAN handles this very well. 
MSC/PATRAN reads each of the separate cards 
and then internally offsets the MPC id for each 
one. This particular offset is not user controllable. 
In version 6.2 this offset is fixed at 1 which caused 
no problem. In version 7.0 the fixed offset was 
changed to 10000. This caused the offset numbers 
to clash with other rigid element entities. 
Fortunately the journal file could be reordered 
somewhat to avoid this problem. 

CONCLUSION 

The task of integrating a structural Finite element 
model that has been developed by several modelers 
from several companies is challenging. This task 
has unquestionably benefited from all the tools 
made available through the currently available 
CAE packages. There are, however, strategies that 
can be brought to bear that can smooth the process 
greatly. Even with many of these strategies now 
being included in the next generation of CAE 
packages the model integrator’s understanding of 
them is essential. This is particularly true with the 
variety of sources of models being integrated. 
These strategies are best used early in the project to 
lay a good foundation for integration. A strategy 
has been presented here that consists of six 
decisions that need to be made. These six decisions 
are: purpose of model, units, common material list, 
model numbering, interface control, and archive 
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format. This strategy has been proved and 
expanded from experience on the X-33 vehicle. 
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Figure 1. Cut-away View of X-33 Structural Finite Element Model 
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Figure 2. Sample From Lockheed-Martin Michoud’s ICD 1 
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-24.4025-54.8843 


SINTEG 

SGRID 

206071 


90.6082 

-34.4397-50.3431 


SINTEG 

SGRID 

206072 


88.8646 

-42 . 9592-43.4527 


SINTEG 

SGRID 

206073 


87.2218 

-50.5425-34.7178 


SINTEG 

SGRID 

206074 


85.9128 

-55 . 9197-24.4057 


SINTEG 

SGRID 

206075 


84.375 

-59. 8319-. 138199 


SINTEG 

SGRID 

206076 


84.1082 

-58.4137 14.6675 


SINTEG 

SGRID 

206106 


94.4133 

-14.294 -57.5103 


SINTEG 

$ 






SINTEG 

$$ LOX 

Tank interface 

grids 



SINTEG 

SGRID 

9002200 

0 91. 

1770-4.40900 58.6340 

0 

SINTEG 

SGRID 

9002201 

0 91. 

2170-3.94700 59.5200 

0 

SINTEG 

SGRID 

9002202 

0 92. 

9000-4.70600 5B.7110 

0 

SINTEG 

SGRID 

9002203 

0 92. 

9400-4.24400 59.5970 

0 

SINTEG 

SGRID 

9002206 

0 91. 

1770 4.40900 58.6340 

0 

SINTEG 

SGRID 

9002207 

0 91. 

2170 3.94700 59.5200 

0 

SINTEG 

SGRID 

9002208 

0 92. 

9000 4.70600 5B.7110 

0 

SINTEG 

SGRID 

9002209 

0 92. 

9400 4.24400 59.5970 

0 

SINTEG 

SGRID 

9102224 

87 . 

8638 43.7069-18.566 


SINTEG 

SGRID 

9102225 

39 . 

2716 36.9369-24.681 


SINTEG 

SGRID 

9102226 

90 . 

9599 28.3519-29.6469 


SINTEG 

SGRID 

9102227 

93 . 

1857 16.438 -33.1889 


SINTEG 

SGRID 

9102250 

92 . 

2647-21 . 4419-32 . 091 


SINTEG 

SGRID 

9102251 

92 . 

2647 21.4419-32.091 



Majority of model, 
including grids that do not 
interface with any other 
models. 


Interface grids to 
downstream bulkdata files. 
This is the first time they 
are defined for the 
NASTRAN analysis. 

They are part of this sub 
model but grouped here for 
convenience. 


Interface grids to upstream 
bulkdata files. They are 
commented out to avoid 
conflict in the NASTRAN 
analysis. They can easily 
be uncommented for 
stand-alone analysis or 
stand-alone PATRAN 
database. 


Figure 3. Sample of Bottom Portion of a Sub Model Bulkdata File 
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